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(57) Abstract: Client databases are synchronised by storing a synchronisation engine (10) maintaining a synchronisation table (20) 
of record identifiers and change indicators for records of the client databases. The table (20) is used during a synchronisation session 
and is maintained persistent between sessions. All client databases (DBA-DBD) are synchronised in a session. Values for identifiers 
and change indicators are received from the client databases and are compared with the stored values to determine if a record has 
changed. The current value is thus identified. All of the client databases are updated with conent value of a leooid and updating die 
synchronisation table is updated for a next synchronisation session. 
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"Synchronisatioii of databases" 

INTRODUCTION 

5 Pidd of flie Invention 

The invention relates to synchronisation of data across multiple databases even if the 
databases have different structures. For example, a contact record in a mobile phone 
database should contain the same data as a record in an email system contact 
1 0 database of the user and referring to the same contact 

Prior Art Discussion 

Heretofore, synchronisation is often performed by direct point-to-point updating for 
15 two databases. Where more than two databases are involved, synchronisation is 
typically achieved by daisy-chaining point-to-point sessions between pairs of 
databases. This approadi, however, suffers from the problems of:- 

(a) Synchronisation is not guaranteed to be complete since there is always at least 
20 one database fliat is not present in the process. It can be shown that three or 

more databases can always be in an unsynchronised state irrespective of how 
inany times the links in the daisy chain are reapplied. This fiulure can occur even 
when the data has not been chaxiged by the user; the changes being a result of flie 
synchronisation itself. 

25 

(b) Complexity. As the number of clients grows, the number of possible point-to- 
point links increases. For example, five databases have ten different point-to- 
point links. Also, the process involves applying and reapplying links in order to 
ensiure that all changes have been propagated within the system. 

30 



wo 01/90933 PCT/EPOl/05869 

-2- 

United States Patent Specification No. US5884325 (Grade) describes synchronising 
shared data between computers having similar database structures. When a 
connection is established updates are propagated from the dient to the server and 
vice versa. The server eventually propagates updates to other clients. Because this 
S arrangement provides the server at the centre of a hub linked to all dients it appears 
to be an improvement over the direct point-to-point method described above. 
However, in this arrangement dients will often be out of synchronisation with each 
other. This has the same drawbacks as other point-to-point synchronisation methods. 

10 The invention is therefore directed towards providing an improved synchronisation 
system and method. 

SUMMARY OF THE INVENTTON 

1 5 According to the invention, there is provided a synchronisation system comprising a 
syndironisation engine comprising means far communication with a plurality of 
dient databases and for updating the dient databases with current data leceived by a 
dient database, diaracterised in that, 

20 die syndironisation engme comprises means for performing a syndironisation 

session m wtddb all dient databases (DBA-DBD) are updated with cunent 
data. 

Thus, all dient databases are synchronised at the end of tibie session until the next 
25 session. This is a major benefit for data int^ty. 

In one embodiment, said engine comprises means for maintaining a synchronisation 
table storing an identifier and a diange indicator for each record of each dient 
database, for comparing the stored change indicators with those read from the dient 
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databases during a synchionisation session, and for maintaniwig the table in a 
persistent manner between synchronisation sessions. 

In another embodiment, the system comprises a client interface associated with each 
S dient database, each dient inter&ce comprising means for providing a universal 
format for transfer of data to and from tibie engine independently of the client 
database format 

In one embodiment, the synchronisation engine comprises means for prompting user 
10 input of instructions if a conflict arises in which a record has changed in more than 
one client database. 

In another en:ibodiment, the engine comprises means for determining that there is a 
conflict if there are differences between records at the field level. 

15 

In a further embodiment, the engine conqnises means for outputting representations 
of the conflicting fields in a universal format 

In one embodiment, the engine comprises means for adding or deleting databases as 
20 dients by adding or deleting corresponding datasets such as columns in the 
syndironisation table. 

In another embodiment, the engine comprises means for Tnaintain^p g a master 
database of current data. 

25 

In a further embodiment, die engine comprises means for using the master database 
as a client database when a dient database is temporarily unavailable. 

In one embodiment, tibie engine comprises means for temporarily Tnaslring a dataset 
30 for a temporarily unavailable dient database. 
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In another embodiment, the engine comprises means for mamf aiTiing a status 
mdicator in the sync±a:onisation table to indicate availability status of a 
corresponding client database. 

5 

In one embodiment, the status values indude uncreated, unsyncfaronised, 
synchronised, and null. 

In another embodiment, a client interface comprises means for maintaining an 
10 intermediate database of true values for truncated values in the associated client 
database. 

In a further embodiment, a client inter&oe comprises means for maintaining a 
persistent database to allow transformation to provide a universal format to the 
IS engine. 

In one embodiment; a dient interface conoprises means for Tnainf atning a 
personalisation table containing a master identifier, a native identifier, an updated 
flag for every associated record, and a current record identifier list, and the dient 
20 interface comprises means for using said data to Tnainff iifi a client database having a 
subset of the records of other dient databases. 

According to another aspect, the invention provides a method for syndironising a 
plurality of dient databases in a single synduronisation session, the method 
25 comprising the steps of: 

storing a synchronisation table of record identifiers and change indicators for 
records of the dient databases; 
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leoeiving the values for said identifiers and change indicators from the client 
databases, and compaxing the xecdyed values vin&i the stored values to 
determine if a record has chan^d to determine the current value; and 

S updating all of the client databases wiffa a current value of a record and 

t^dating the synchronisation table for a next synchronisation session. 

DETAILED DESCRIPTIQN OF THE INVENTION 

10 Brief Description of the Drawings 

The invention will be more dearly understood fi'om die following description of 
some embodiments thereof given by way of example only with lefeience to the 
accompanying drawings in which:- 

15 

Fig. 1 is a schematic representation of a nuniber of databases interconnected 
for synchronisation, 

Fig. 2 is a generalised diagram illustrating the architecture; 

20 

Fig. 3 is a schematic representation of a synchronisation table generated 
during a synchronisation process; 

Fjgs. 4(a) and 4(b) are together a flow diagram of synchronisation; 

25 

Figs. 5 and 6 are sample tables indicating system states; 



Fig. 7 is a sample conflict resolution dialog; 
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Fig. 8 is a set of sample records and corresponding entries in a 
synchronisation table; 

Fig. 9 is a representation of sync, table columns to handle disconnected 
5 clients; 

Fig. 10 is a representation of handling of truncated fields; 

Fig. 1 1 is a logical view of a transformation operation; and 

10 

Fig. 12 is a representation of personalisation components. 
Description of the Embodiments 

IS Referring to Fig. 1 a user's PC 1 is programmed to perform a process to synchronise 
a database 2 on the PC 1, a database 3 m a server 4, an Intemet database 5» and a 
database 6 of a mobile phone 7. This is one example scenario. At a general level 
and referring to Fig. 2, synchronisation is performed by a synchronisation system 
comprising: 

20 

a synchronisation engine 10, and 

a dient interface C'dient'') 11 associated with each application A, B, C, and D 
having an associated API and a database DBA, DBB, DBC, and DBD 
25 respectively. 

For synchronisation there are multiple databases and so the basic architecture is in 
die form of a hub with the engme 10 in the centre and a client 1 1 for each database. 
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The engine 10 generates a synchronisation table 20, as shown in Fig. 3. This table 
has a row for each item (such as a contact) and two coliunns for each database. The 
two columns contain for each item a unique identifier (UID) and a change indicator 
(CI). These two columns are derived direcdy from the databases. The CI is the ''last 
5 modified timestamp'' where available, and if not available a Cydic Redundancy 
Check (CRQ may be generated direcfly fit)m the data having a high probability of 
detecting that a record has changed. 

When synchronising a record across the databases the UID and CI for each of the 
10 corresponding records firom each of the databases is stored. They are stored in a 
logically linked manner, so that in future synchronisation sessions the linked records 
can be compared 'like-Avith-like'. The synchronisation table contains the UIDs and 
the CIs for all synchronised records in all of the configured dient databases 
(synchronisation points). Each colxmm in the synchronisation table corresponds to 
IS aU of the synchronised records for one of the databases. Each row in the 
synchronisation table corresponds to a record that is linked by synchronisation 
between data stores. The synchronisation table is persistent, i.e. its state is saved 
between synchronisation sessions. 

20 The engine 10 is an independent er^e that provides aU of the synchronisation 
processing, including dup]icate handling, conflict resolution, and overall control of 
the synchronisation process. It inVokes the indhridttal clients 11, and requests fix>m 
them data about die current state of their devices/applications and instructs diem to 
write back informadon to the device/applications. It provides a generalised interface 

25 for each different device or application. The engine 10 is responsible for maint aining 
the synchronisation data. 

Each client 11 is aware of the format and API offered by the associated application 
and handles all communication with it Each dient 11 isolates the engine 10 from 
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fhe specific detail of how mfoimation is stored in the applications. The clients 11 
also provide: 

• Application-specific configuration dialogs. 

• Application-dependent storage of non-synchronisable data, such as voice dialling 
5 tags on phones. This infornoiation is managed by die clieht 11. 

The APIs are conventional APIs for third party access to content. The 
synchronisation process uses these APIs to read and write information to the 
databases in their own proprietary formats. 

10 

The interface between tibe engine 10 and the clients 11 defines a common and 
consistent universal format containing all of die fields required for syndbronisation. 
The engine 10 stores a xxmtct database of all synchronised data in the universal 
format. 

15 

Referring to Figs. 4(a) and 4(b), the synchronisation process uses the d value fi'om 
the clients 11 to determine (by checking with the synchronisation table) if there is an 
edit conQict. Resolving the conflict involves writing to the universal (or master) 
database the value from the database having the most recent update as indicated by 
20 the CI. If more than one database has an updated CI then user input may be 
required. Where a new record is detected die engine 10 creates a new row in the 
sync, table. If the ''new" record is a duplicate the engine 10 makes a link to an 
existing record after searching key fields and possibly with user input. Any conflict 
with the new record is resolved as described above, again possibly with user input. 

25 

When the engme 10 has processed all records firom all dient databases it has an 
updated master database. It then updates the dient databases by ddeting required 
records, updating edited records, creating new records and applying personalisation 
(described in more detail bdow). The sync, table is then saved to file. 
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In the above process, there is conflict resolution where a record representing the 
same information has been amended in more dian one client database. This is 
known as a conflict and the records are termed as conflicting records. In the case of 
a conflict^ tiiere is a need to enable the user make a decision as to which record 
S accurately reflects the current data and communicate that decision to the 
synchronisation engine. FurAermore, there may be occasions where a number of 
fields within each record have been modified where the current correct data is in feet 
spread across the conflictmg records. In this latter case a simple selection of one of 
the conflictmg records as the master would not ensure tiiat the correct information is 
10 written back to each of the client databases as a result of the synchronisation process. 
It is of significant benefit for the user to be able to select individual fields from the 
records in conflict to produce a merged new record, so fliat all fidds in the 
synchronised record are up-to-date at the end of synchronisation. 

IS A conflict can also occur ifthere is a new record in one oftheappUcations, which is 
being synchronised for die first time, that has been identified to be duplicate of one 
that already exists in the synchronised record set (by using the key fields to identify 
the duplicate). In this case, the non-key fields (i.e. those which were not used to 
identify a new contact as an existing one) are candidates for conflict resolution. 

20 

During the synchronisation process, the engine 10 retrieves all of the edited records 
and new records firom all the applications in the universal record format via the 
dients 11. Having all records available in the universal format allov^ fidd-level 
conflicts to be detected consistentiy: 

25 

Where a synchronised record has been edited in more than one application, the 
edited universal record representations are compared fidd-by-field to determine 
which fidds of flie record are in conflict If there are fidds in conflict, the conflicting 
fidds are identified to the user, via a user interfece so that they are able to identify 
30 die correct data, in other words, resolve the conflict If no conflicting fidds are 
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fbund, because each of the changed fields in each of the conflictmg lecords were 
changed to the sanoie new value(s), then there is no conflict to resolve even though 
the records are in conflict In this latter case, the solution is intelligent enough to 
proceed without the need for user intervention. 

5 

Fig. 5 illustrates the state of the system after the last synchronisation and Fig. 6 
illustrates the state of the system prior to the next synchronisation when the same 
record has been edited in both applications. The column marked K is the user's key 
fidd for tiie record (i.e. what they would typically use to identify the record; in the 

10 case of a contact database this might be the contact's full nanie). The 
synchronisation table indicates that die two records in the separate applications 
represent the same information. Comparison of the change indicators (CI) for each 
application in the row of the synchronisation table with the values stored in the 
application indicate that die record has changed in both applications. Field by field 

15 comparison indicates that there are two fields in conflict, namely the first and the 
forth fields. It is important to note that, though the third field has changed (to 
Kiwis), it is not in conflict as the identical change has been noade in both records. It 
should also be noted diat die forth field is in conflict even though a change has been 
made to that field in only one of the records. 

20 

In order for die user to be able to resolve the conflicting fidds of the records, the user 
must be presented with the information in universal recoxd format fiiom each of the 
conflicting records, which have been collated during the conflict-detection phase. 

25 The user interface for the conflict resolution consists of a PC-based dialogue 
displaying a table view whose columns correspond to die fidds of the universal 
record. The header of die table identifies the content of each column. The first 
column of the table identifies for each row of the table where the rov^^ data is derived 
from. The top row of the table view displays the resultant resolved record. This 
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record does not diiecdy- coirespond to any real record in a database; it is the 
'working' record, vAndi the user is resolving. 

The rows in the conflict resolution table view of Fig. 7 show the universal record 
5 rqrcsentation fironi eadi of the appUcatiom for &e conflicting rcOT^ There must 
always be at least two additional rows displayed, since these rows correspond to the 
conflicting records. To assist flie user in the conflict resolution process, the columns 
of the table view are re-ordered, so Aat the fields that are in conflict are displayed on 
the far left of the table. In addition, the conflicting fields are highlighted in bold to 

10 distinguish them fi-om the non-conflicting fields. This quiddy draws the attention of 
the user to the fields which are in conflict, so that they noiay resolved with the 
minimum difl&culty. The user chooses the most up-to-date fields firom the conflicting 
options, by clicking directly on the field value required in the table view. This causes 
tibie field value in the resolved record (displayed in the top row) to be updated to tliis 

IS last selected value. 

When the user has completed merging the conflicting records, he positively aflBrms 
die merg^ (by diddng on an OK button). This causes the fields cuizenfly displayed 
in die top row to be stoied in die master database as the 'resolved record*, and 
20 subsequendy to be written by each of the clients to their respective applications . 

There is an arrow head to the left of each of the rows representing conflicting 
records. This is a row selector button enabling the user to select a v^ole row as the 
rowtobeused. 

25 

The above describes the ^ case where the same field is updated ia all conflicting 
records to exacfly the same value and fliis means fliat there is in fact no conflict to be 
resolved. There is one ftirther case where there is no conflict to be resolved, even 
when a conflicting record is detected (i.e. the same record ia multiple applications 
30 has been editecQ. This case occurs when the dififerent applications support a different 
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subset of fidds of the universal record. Fig. 8 illustrates tiiis. In Fig. 8 we see that the 
field change in Application A* does not appear in Application B\ and similarly the 
field change in Application B' does not occur in application A'. In this instance* a 
single mer^d universal record can be derived torn the information in both the 
5 conflicting records without the need for user intexventioiL 

Thus, the invention provides the following features: 

Full field-level conflict resolution, with the ability to merge up-to-date fields 
10 firom record edits in different data sources. 

Ability to detect and handle the situation where identical changes have been 
made to the conflicting records and merg^ them without the need for user 
interaction. 

15 

Ability to detect and handle situations where changes have been made to 
conflicting records containing non-intersecting sets of changed fields. Again, 
in this instance, there would be no need for user interaction . 

20 Addition and removal of dient databases is adiieved in a simgple manner 

wifliout desfabilisation of the system. 

When a new client is configured, a new column is added to die sync, table. The 
entries of the new column are initialised to have a synchronisation state of 
25 'unsyndironise(i\ During the next synchronisation, this *unsynchronised' state 
tri^ers the engine 10 to syndironise all the entries in the master database with the 
newly configured data store. When a dient is removed, a column is removed firom 
the table. This has no fiirther effect on the synchronisation process, apart from 
redudng the number of dient databases to be synchronised by one. 
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The invention also handles tiie situation where one of the clients is temporaiily 
unavailable. This might occur, for example, if one of the databases to be 
synchronised happens to be a handhdd device for which the battery has expired, or if 
the connection to the database is unreliable, as it might be for an Ihtemet-based 
S database, bi sudh a case, it would be highly inconvenient if the unavailabiHty of 
of the configured databases were to prevent the synchronisation of the remaining 
databases. Ftovision of the synchronisation table together with the master database 
allows for clients to be temporarily unavailable during any given synchronisation. 
By masking out one of the colimms of die table, thus hiding it from the 
10 synchronisation process, synchronisation of all the remaining available databases can 
continue. The existence of the master database ensures that the overall record-set is 
always available in universal format. When the databases becomes available again 
for synchronisation, its column of the table becomes visible to the engine, and its 
data set is synchronised. 

15 

To support discoimectable clients, the synchronisation table also contains a status 
* fidd in die table, which is used by the engine 10 to determine the required action to 
take, as shown in Fig. 9. The status table entry may take on one of the foUowiqg 
. values: UNCREATED, UNSYNCED, SYNCED, or NULL. 

20 

If an attenipt is made to create a record in a client 11 which is discoimected, the 
create fidls, and status is set to UNCREATED. This records the £ict diat it failed, so 
that on subsequent synchronisation sessions, the create can be re-tried, if an attempt 
is made to edit a record in a dient 11 which is disconnected, the edit fails, and the 
25 status is set to UNSYNCED. This records die fact fliat it failed, so tiiat on 
subsequent synchronisations, the edit can be re-tried. If the dient 1 1 is coimected, so 
that creates/edits succeed, the status is set to SYNCED. 



30 



If a record is deleted in another (coxmected) dient 11, the engine logic deddes to 
propagate the ddete across all dients 11. For all successful ddetes, die 
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cozresponding synchrozusation table entiy status is set to NULL. If one of the dients 
11 is disconnected at tbe point the record delete request is made, the delete fidls, and 
the status is set to UNSYNCED. Because the synchronisation table row is not 
removed from the table until all entries' status is NULL (indicating successful 
5 deletions), the engine is able to re-try the deletion. 

The NULL status is also used as part of a personalisation solution; if a table entry's 
status for an external dient 1 1 is NULL, and the status for the corresponding entry in 
the column for the master database is non-NULL, then the entry for the external 
1 0 dient 1 1 represents a record that is exduded from the personalisation set 

This technique for handling disconnected dients is equally applicable to the case 
where the database is physically unavailable, or where the user has dected to omit a 
given database from the synchronisation. When configuring clients 11, there are 
15 three options available: (a) always synchronise the database, (b) prompt the user for 
whether to synchronise the database, of (c) never syndironise the database. 

Thus, the invention provides the ability for the user to control, at synchronisation 
time, the database (dients) that win be synchronised. It also provides the ability to 
20 complete simultaneous multi-point synchronisation across a set of applications when 
one or more are not available to participate in the synduronisation. On thenexttime 
an application re-joins the syndironisation process, to be able to pidaip "pending 
dianges'' from previous synchronisation sessions. 

25 In the multipoint synchronisation process the aim is to ensure eadi partidpating 
database maintains as frdtfafol a copy of the information stored in each other 
database as possible. In the situation where the structures of the diflFerent datastores 
differ, this may involve some transformation in the format of the data. There may 
also be limits on die fidthfahiess of the data representation imposed by the size 

30 limitations of the storage structures in the different datastores. In most cases when 
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synchionismg mfonnation in PQ Server or Internet based databases the size 
limitation imposed by different databases do not practically afiect the 
synchronisation as the fidds are usually sized to cater for the majority of data that a 
user might use. Even if there is some truncation this usually occurs in a sufficiently 
S small amount of cases to have negUgible affect. 

However, when providing multipoint synchronisation for mobile devices, a very real 
problem is faced. A typical mobile phone may limit the storage of a name in its 
contact datastore to say 12 characters. Synchronising a PC database such as 
10 Outtoolc^ to phone and back again presents a potential problem as illustrated below: 



Original record in Ouflook™ 



Key 


Name 


Number 


A 


Samantha Fielding 


1-555-457-7845 



15 



20 



Resulting tecord in phone (12 character name restriction) 



Key 


Name 


Nmnber 


A 


Samantha Fie 


1-555457-7845 



Now, if a user changes the record on the phone, amending the number to 1-555-457- 
jjj^, the phone's record would read: 

New record in phone 



Key 


Name 


Nmnber 


A 


Samantha Fie 


1-55S457-8888 



Using standard record-level synchronisation, the Oudook™ record would then 
become 



Key I Name 



Number 
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Samantlia Fie 



1-555-457-8888 



10 



This reduces the Oudook™ xecotd to the storage liimtation of the phone. Without 
special handling all datastoies involved in the synchronisation risk being limited to 
the storage capabilities of the phone (for those fields stored on die phone). Referring 
to Fig. 10, in order to ensure correct synchronisation a dient 11 maintains a 
persistent Intermediate Datastore to store a copy of the original universal record (or 
at least a copy of all the fields that could be subject to truncation) and its 
corresponding truncated data. This enables the dient to detect changes to the 
truncated data in the application datastore by comparing the truncated data currently 
in the application datastore with the truncated data that was stored in the 
Intermediate Datastore. 



15 



20 



The synchronisation is driven by the engine 10 requesting dients to read and write 
records to the databases. In a vmte request the dients are responsible for translating 
the record in universal record format as given by the engine 10 into the application's 
record format and conversdy, in a read request the dients 11 are responsible for 
translating the record &om the applications format to the universal record format. 
To handle truncation, the following additional processing is required (referring to 
Fig. 10 for nomenclature). 

Basic write request fix)m the engine. 



Convert universal record format to database format 



25 



Create a record in the dienfs Intermediate Datastore, containing for each 
fidd that could be truncated, a copy of the pre-converted fidd data (true 
value) and a copy of the fidd data after conversion and possible truncation 
(converted value). 
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Wiite the lecord in database fonnat to the database. 

Basic read request from engme 

5 Read lecord from database 

Read corresponding record from Inteimediate Datastore. 
Convert record to universal record format 

10 For each field that could be truncated, compaie the value returned from the 

application with the converted value stored in the dienf s Intermediate 
Datastore. If the values match, replace the field in the universal record with 
true value from the dienf s Intermediate Datastore. 

IS Pass the universal record back to the engine. 

This process prevents the loss of data through the propagation of truncated data 
during the synchronisation process. 

20 Fig. 11 illustrates use of the Intermediate Datastore in more detail. The universal 
record structure lutermediate Datastore is represented on the left and die application- 
specific record structure is represented on the rig^t. The client is responsible for 
translating the common fields in botfi records from one format to the other. Fig. 11 
shows the universal record, having a unique id (UID) and fields Y, Z, and A - G. 

25 The application record has a corresponding UID and fields A - H. Both records 
have in cormnon the UID and common fields A - G. 

Fields A - D and F have the same representation in both records, so the dient needs 
to do no processing other than copy one to the other. 



wo 01/90933 PCT/EPOl/05869 

-18- 

Fidd E is represented in die app&cation datastoie in a different way to the universal 
record but has a reversible transformation (R) between the two representations. All 
the client needs to do is perform this transformation in the appropriate direction 
when requested to read or write a record by die engine. An example ofthis might be 
S a priority Md, represented in the universal contact record as values 1,2 or 3 and is 
represented in the application's datastore as "high", "medium*' or "low'\ 

Field G has a one-way transformation (T) from G to G". In this case tmiversal 
representation and the application specific representation need to be stored in the 

10 client* s Intexmediate Datastore during a write operation to the application. This 
information is used during a read operation to determine whether field G'* has been 
changed by the user. If it has not, The dienf s Intermediate Datastore's copy G is 
used to construct the universal record using its correct value (i.e. before 
transformation T has been applied). This process enables individual clients 11 to 

IS transform the data to a .more suitable fomoat whilst ensuring that any unedited 
transformed data is not propagated to odier clients. 

When synchronising records between a number of datastores ifae synchronisation 
engine ensures that, at the end of the process, each datastore contains a 
20 representation of all of the records, for example, each datastore would contain n 
records. 

There are a number of scenarios in which it would be beneficial for one or more of 
these datastores to contain only a subset of the enture record set. These include, but 
25 are not limited to: 

a. Limited storage capability. The datastore does not have the capacity to store all 
of the records. This can typically occur with devices such as mobile phones. 
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b. Data manageability. A large set of records may d^ade the perfimnance or 
usabili^ of the application that manages them. 

c. Minimising synchronisation time. Interaction with a data store may be time- 
5 consuming and so reducing the quantity of data can improve the speed of 

synchronisation. 

d. Ridevant data. A Personal Digital Assistant (PDA) user may only want records 
associated with their next business trip. 

In this specification, the ability to synchronise a subset of records is termed Subset 
Personalisation. With regard to multipoint synchronisation, the engine is responsible 
for the actual synchronisation functionality such as conflict resolution and duplicate 
handling. A client that supports Subset Personalisation is responsible for managing 
the subset The following describes how such a client can be implemented. 

A requirement is for there to be a database containing all records in the 
synchronisation set. This database needs to be accessible at every syndhionisation 
session. It also needs to contain records tiiat support aH universal field data. The 
20 master database satisfies tiiese requirements. 

The client 11 uses a Personalisation Table and a Current UID List. The Cunent 
UID List contaim a list oftiieUIDsofaDoftfae records in the iiativedata^ The 
list is g^erated at the start of a synchronisation session and is discarded 

25 the session. The Personalisation Table contairis three coluinns- Master UID, Native 
UID and Updated. The table has a row for every entry in the Personalisation subset. 
The Master UID value is the UID of the record in the Master database. The Native 
UID value is the UID of the corresponding record in the native database. The 
Update value is a flag denoting whether an entry has changed. The table is persistent 

30 between sync. Sessions. Fig. 12 illustrates these conq>onent5. 
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Subset Personalisation is achieved during synchronisation as follows. At tihe start of 
the process, the dient initialises each value in tiie Updated column of the 
Personalisation Table to FALSE. It extracts a list of die UIDs and CIs of all of the 
S records in the native database. Using tiiese values, it updates the Change Status 
column in the sync table accordingly. It also creates the Current UID List from all of 
the UIDs in the native database. 

For every new record that it finds, the client adds a new row to the Personalisation 
10 Table, setting the Native UID value to that of the new record and setting the 
Updated flag to FALSE. The Master UID value is set to NULL. During the 
synchronisation process, die engine may instruct the client to Delete, Edit or Create 
records. The dient processes these instructions as follows: 

15 Delete Record 

The dient uses the supphed Native UID to find the entry in the Personalisation 
Table and removes tfiat row. 

Edit Record 

20 The dient uses the supplied Native UID to find the entry in the Personali3ation 
Table and sets the Update value of the entry to TRUE. 

Create Record. 

The dient does nothing. 

25 

When an changes have been applied to all of tihe dients, the engine instructs each 
dient to personalise its data set (if supported). When the dient detects new records, it 
added new rows to the Personalisation Table with die Master UID set to NULL 
(since tiie Master UID is obviously unknown at tihiat time). At this stage, as part of 
30 the synchronisation process, the UEDs of the new records will have been inserted at 
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the appropriate positions in die Sync Table. Hie client now searches die 
Personalisation Table for these entries. For each one that it finds, it* 

a. reads the Native UID of the entry 

5 

b. uses the Native UID to search the Sync Table to determine where the entry was 
applied, 

c. retrieves the Master UID for that Sync Table entry, and 

10 

d. applies the Master UID to the Personalisation Table row. 

The set of records that make up the Personalisation Subset can be specified in a 
number of ways. These include, but are not limited to: 

15 

a. User sdection. The user is provided widi a list of all of the records and can select 
those records that are to make up the subset 

b. Rule based selection. The user sets some criteria that a record must satisfy for 
20 inclusion in the subset e.g. Country = USA. 

A key difierenoe between tibiese two metiiods is that, in the former, the 
Personalisation Set can vary during the process due to deletions in any dient or new 
records in the native database. However in the latter mediod, the Personalisation Set 
2S can vary during the process as a result of deletions, edits and new records from any 
client. At this stage, the master database contains all of the records with the latest 
data. A dient using the rule based method now needs to update its Personalisation 
Table entries. For each entry in the Personalisation Table, the dient: 

30 a. reads the Master UID, 
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jretrieves the associated record from tbe Master database, and 

checks whether tiie rule criteria are satisfied. If not, that entry is removed bam 
the Personalisation Table. 

The dient now reads each record in the master database. For each record, it checks 
whether the rule criteria are satisfied. If tiiey are, and die entry is not currently in the 
set, the dient creates a new entry in the Personalisation Table. The new entry has the 
10 Master UID value applied, the Updated fidd set to FALSE and the Native UID 
value set to NULL. The Native UID value will be set when the record is created in 
the native database. 

At this point, 

15 

a. the Personalisation Table is now fiilly populated witii the conect data and 
contains an entry for eadi record in the subset 

b. the Master database contains all ofihe records with the latest data. 

20 

c. theCun:entUIDListcontaimalistof(heUn3sofanof1faeiecordscuirentiym 
the native database. 

The dient now applies the actions (Ddete, Edit, Create) needed for the 
25 Personalisation Subset 

Ddete 

If a Native UID in the Current UID list does not have a corresponding entry in the 
Personalisation Table then that record is ddeted in the Native database. 



b. 
c. 

5 



30 
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Create 

If a Native UID valve in the Peisonalisation Table is NULL then a new xecord is 
required in fbe Native database. The dient 11 uses the Master UID entry to retrieve 
the comet record from the Master database and creates a corresponding record in 
5 the native database. The UID of the newly created record is stored in the Native UID 
column. 

Edit 

If a Native UID in the Current UID List has a corresponding entry in the 
10 Personalisation Table and the Update value is TRUE then that record needs to be 
edited in the native database. The dient uses the Master UID entry to retrieve the 
correct record from the Master database and updates the corresponding record in the 
native database. 

IS When all actions have been applied, the subset of records are syndironised and the 
syndironisation process is complete; 

It win be appreciated that the invention achieves the following advantages. 

20 Ability to control the records from die overall available set of records which 

are lequued to be synchronised to any given data store, by using either 
explicit sdection or rules based selection. 

Enabling datastores of limited storage ability to be syndburonized with large 
25 data stores. 

Inqproving data managability. 

Reducing synchronisation time. 
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Allowing the user to synchronize only relevant data. 

Having a (well thought out) defined universal record format at the outset enables a 
developer to provide all the mappings and transformations within ibe engme during 
S the coding stage and only needs to requne the user to map fields during the setup of 
the synchronisation in extreme cases. This reduces the risk of user error and 
confusion. It also simplifies ttxc process of user configuration of die synchronisation 
process. 

10 Furthermore, by ensuring that the engine stores its data in the master datastore in the 
universal record format, no internal transformations are required and all 
comparisons required to do the synchronisation are independent of the applications 
being synchronised. This enables the mcremental development and addition of new 
clients without requiring any change to the engine. 

15 

Exposmg the universal record format to the user through the user interface has a 
number of additional benefits; naindy: 

• The user can get a view of his synchronised data in a common format 

• The user can see all data that is partaldpg in the synchronisation (viewing it 
20 through the inter&oe of one of the Application may not expose all the 

information partaking in the synchronisation.) 

• When displaying conflicts in records fix)m two or more applications, the user is 
able to see the conflicts in a corxmion format 

25 Thus, flie invention enables the incremental adding of dients to a multi-point 
synchronisation process without the need to: 

• test every other synchronisation dient, 

• be aware of any oAer record format other than the universal record format, and 

• to amend the core synchronisation product 
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The iavention is not limited to the embodiments described but may be varied 
construction and detail. 
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1. A synchronisatiQii system comprising a syncbromsation engine conxprising 
means for communication with a plurality of dient databases and for updating 

5 the dient databases witli current data received by a dient database, 

diaracterised in that, 

the synchronisation engine (10) comprises means for performing a 
synchronisation session in which all dient databases (DBA-DBD) are iqidated 
10 with current data. 

2. A syndironisation system as daimed in daim 1, wherein said engine comprises 
means for maintaining a synchronisation table (20) storing an identifier and a 
diange indicator for eadi record of eadi dient database, for comparing llie 

IS stored diange indicators with those read from the dient databases during a 

synchronisation session, and for maintaining the table in a persistent manner 
between syndironisation sessions. 

3. A syndironisation system as daimed in daim 2, wherein the system comprises 
20 a dient interlace (1 1) associated with eadi dient database, eadi dient interface 

comprising means for providing a universal format for transfer of data to and 
from the engine independently of the dient database format. 

4. A synchronisation system as daimed in any preceding daim, wherein the 
25 synchronisation engine (10) comprises means for prompting user input of 

instructions if a conflict arises in whidi a record has changed in more fban one 
dient database. 

5. A syndironisation system as daimed in daun 4, vdierein the engme (10) 
30 comprises means for determining that there is a conflict if there are diflSacences 

between records at the fidd levd. 



10 
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6. A syndbronisation system as daimed in claims 4 or 5, wherein tibe engine (10) 
conqnises means for ou^utting lepresentations of die conflicting fields in a 
universal format 

7. A synchronisation system* as claimed in any preceding daim, wherein the 
engine (10) conoprises means for adding or ddeting databases as clients by 
adding or deleting corresponding datasets such as columns in the 
synchronisation table. 

8. A synchronisation system as daimed in any preceding claim, wherein the 
engine (10) comprises means for maintaining a master database of current data. 



9. A synduronisation system as daimed in daim 8, wherein the engine comprises 
IS means for using the master database as a dient database when a dient database 

is temporarily unavailable. 

10. A synduxmisation system as daimed in daim % wherein the engine (10) 
coniprises means for temporarily masking a dataset for a teinporarily 

20 unavailable dient database. 

11. A syndironisation system as daimed in daim 10, wherein die engme (10) 
conqxrises means for maintaining a status indicator (5) in the syndironisation 
table to indicate availability status of a corresponding dient database. 

25 



12. 



A synduonisation system as daimed in daim 11, wherein the status values 
indude uncreated, unsynchronised, synchronised, and null. 
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13. A synchronisation system as daimeid in any preceding claim, wheiein a dieht 
inter&ce comprises means fpr maintaining an intermediate database of true 
values for truncated values in Ae associated dient database. 

S 14. A synchronisation system as daimed in any preceding daim, wherein a dient 
inter&ce comprises means for maintaining a persistent database to allow 
transformation to provide a universal format to the engine. 

15. A synchronisation system as daimed in any preceding daim, wherein a dient 
10 interface comprises means for maintaining a personalisation table containing a 

master identifier, a native identifier, an updated flag for every associated record, 
and a current record identifier list, and the client interface comprises means for 
using said data to maintain a dient database having a subset of the records of 
other client databases. 

15 

16. A method for synchronising a plurality of dient databases in a single 
synchronisation session, the method compiisiDg the steps of: 

storing a syndironisation table of record identifiers and diange indicators for 
20 records of the dient databases; 

receiving flie values for said identifiers and change indicators fi'om the dient 
databases, and comparing the received values with the stored values to 
determine if a record has dianged to determine the current value; and 



25 



updating all of the dient databases with a current value of a record and 
updating the syndironisation table for a next synduronisation session. 



30 



17. 



A computer program product comprising software code for performing the 
method of daim 16 when executing on a digital computer. 
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